This will be used to make the style check only apply to the locked
Nixpkgs version.

It's redundant because at the `flake.nix` level this was already being
handled.

It's wrong because it's using the `lib` from the `flake-parts` input,
which ***is not*** the `lib` from the `nixpkgs` or `pkgs` input!

So whatever override we were passing for `nixpkgs` wouldn't affect that
`lib`, and thus the `version` on the `lib` was whatever the
`flake-parts`'s Nixpkgs was at.

This is one way Flakes let us down: there is no way to make the `check`
run only when inputs were not overridden, or additional ways to affect
the evaluation.

So, just like Sisyphus, we need to push the version number up every time
the formatting rules change in the formatter that is on the
`nixos-unstable` release we track, compared to whichever versions we run
as additional CI checks.

Instead of handling this manually, let's just look at the locked
version number from the release channel URL.

This unshackles the evaluation of the package from the NixOS evaluation.

Turns out we already basically were at r36.5, and this will have been
the cause of some of the issues getting the GPU drivers going.

This is *basically* the open GPU driver codebase, but in a special Tegra
configuration.

It also is a different branch, with a version number that may not be
matching anything equivalent on the open GPU drivers.

This is not sufficient to have hardware acceleration. The proprietary
drivers also have to be used.

The proprietary driver version *must* match the version of the this
display driver, or else things may not work, or worse.

…nel-display-driver

This was backported as it looked like it may be able to fix the GPU
driver usage with mainline 6.12. It did not.

This did fix the `fbdev` parameter for 6.12.

This is not forced on end-users.

This is provided because it *may* be needed to better support all
features of the platform. Even with OOT drivers, some features won't
work with mainline, or worse.

The `nvidia-l4t` package includes the proprietary libraries, the ones we
don't have the equivalent sources to.

These libraries are where the GPU acceleration lives.

Also introduce `enableStage1KernelModules` to allow end-users the option
to disable the modules.

This *should* generally be done for options that are lists, as those are
poorly composable, and removing an element from a list in the modules
system is generally hard.

When users otherwise don't explicitly care, use 6.12, as `nvidia-oot`
only claims to support up to 6.15, and 6.12 is the prior LTS.

This only sets the kernel using `mkDefault`, so this will not affect any
selection users have made for themselves.

… kernel modules

…ilable

This is used to solve the issue where the NVIDIA drivers are (still)
unable to take control of the device when they are used by a DRM driver.

What's funny here is that this makes the graphics driver work on
mainline 6.12, whereas when using `FBDEV` in the kernel config, starting
xorg would reset the board.

…ules...

This will be managed in the follow-up commit. Refer to it for the
rationale

…ever way

The clever way (trying to “react” on system-wide changes) ended-up
having a race condition that could be triggered in unclear
circumstances... and that race condition *was apparently why it
worked*.

So this rework instead implements that race condition as a feature,
instead of relying on my good luck.

This is still implemented as a `udev` rule as it is the easiest and most
robust method to implement the required dance here:

 - Load `tegra-drm` such that it takes `card1`
 - Unbind `simpledrm` such that it frees `card0`
 - Load `nvidia-drm` such that it takes `card0`

This, it turns out, is the secret sauce to make wayland compositors
*just work* with the L4T drivers.

The load order of the modules was already known to matter a lot: the
`nvidia-drm` driver *must* be loaded after `tegra-drm`. And yes, the
`tegra-drm` module *needs* to be loaded for it to work.

The real difference compared to before is that having `card0` taken by
the `nvidia-drm` driver means that, without some special proprietary
sauce like in the X11 L4T driver or manual configuration, the software
using DRM *should* pick the appropriate card by default.

This matters when some compositors don't really expose a good way to
pick a given `card` or `render` node.

In an ideal world, either the `tegra-drm` would have its devices
unregistered when `nvidia-drm` is loaded, or we could affect the
allocation of the `minor_str` of the DRM devices so that a given device
is prefered, or `nvidia-drm` could be loaded first without breaking.

Alas, we're beholden to the drivers we are given.

This strategy *does not* work when `simpledrm` is not in use. As of this
commit, the use of the vendor kernel as-configured without `simpledrm`
wouldn't work as there is nothing tying the `tegra-drm`+`nvidia-drm`
driver loading to the classic `fbdev` driver. Such systems were *anyway*
broken in the same way previously.

While this is not supported to *build*, we have CI checks against 24.05,
so let's make CI work.

Let's not rely on `fbdev`, even though *it nominally works* for the
vendor kernel. Both the vendor kernel and mainline should nominally work
like the other for the system integration. And that means that it should
enable the `tegra-drm` and `nvidia-drm` modules with the same semantics.

When using the `fbdev` setup, the `tegra-drm` and `nvidia-drm` *are*
effectively loaded (despite the blacklist?) but are loaded in a way
where `card0` is the `tegra-drm` device, which would be a notable
difference for non-X11 graphical use-cases.

…module

Turns out the stack is ***very*** fussy, and there is *something* that
can happen while loading the drivers, if it happens while the system is
kinda busy, and in concurrence with a lot of other things.

The reason this is assumed to be some race condition or similar
situation is that the more things are made to go slowly, for example
with sleep or by adding dynamic debug prints to the kernel, the more
likely things are to work.

So let's stop being clever and reactive about the environment. Instead,
let's just brute-force our way to a working display output, and make the
whole world wait for the driver to load. But only when the graphical
target is involved.

I believe this is something that the vendor is having difficulties with,
as other distributions require turning of “SOC Display Hand-off” in the
platform firmware for accelerated display support, and their newer
Jetpack platform, for AGX Thor, also requires it for the vendor system.
The fact that the vendor ships their kernel with fbdev also points
toward that being true.